Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[ntuple] return const char* instead of std::string from RColumnElemen… #16695

Merged
merged 1 commit into from
Oct 20, 2024
Merged

[ntuple] return const char* instead of std::string from RColumnElemen… #16695

merged 1 commit into from
Oct 20, 2024

Conversation

silverweed
Copy link
Contributor

…t::GetTypeName

This doesn't impose a potential allocation (or the use of std::string) on the caller unnecessarily.

Checklist:

  • tested changes locally
  • updated the docs (if necessary)

@silverweed
[ntuple] return const char* instead of std::string from RColumnElemen…
67f2067 
…t::GetTypeName

This doesn't impose a potential allocation (or the use of std::string)
on the caller unnecessarily
@silverweed silverweed self-assigned this Oct 16, 2024
@silverweed silverweed requested a review from jblomer as a code owner October 16, 2024 08:07
@github-actions GitHub Actions
Copy link

Test Results

    17 files      17 suites   3d 20h 36m 22s ⏱️
 2 712 tests  2 711 ✅ 0 💤 1 ❌
43 509 runs  43 508 ✅ 0 💤 1 ❌

For more details on these failures, see this check.

Results for commit 67f2067.

jblomer
jblomer reviewed Oct 16, 2024
View reviewed changes
Copy link
Contributor

@jblomer jblomer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not quite convinced but I wouldn't object either. This is not a performance-critical method but it's one used for reporting. I think having it return a const char * makes its use in many cases a little more cumbersome (convert to std::string first).

@silverweed
Copy link
Contributor Author

I'm not quite convinced but I wouldn't object either. This is not a performance-critical method but it's one used for reporting. I think having it return a const char * makes its use in many cases a little more cumbersome (convert to std::string first).

Being this a public API we cannot know a priori whether it's gonna be performance-critical for an application or not, so in my opinion we should default to giving the user the most flexibility. I don't think it gets particularly more cumbersome to use, because yes, in some cases it requires wrapping it in a std::string but in other cases it avoids calling .c_str(), so it kind of balances out (and in any case it's a trivial change to make).

@jblomer
Copy link
Contributor

jblomer commented Oct 17, 2024

I think that's a fair point.

@silverweed silverweed merged commit 3619188 into root-project:master Oct 20, 2024
18 of 21 checks passed
@silverweed silverweed deleted the ntuple_column_gettype branch October 20, 2024 10:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@pcanal pcanal pcanal approved these changes

@jblomer jblomer jblomer approved these changes

@hahnjo hahnjo Awaiting requested review from hahnjo

@enirolf enirolf Awaiting requested review from enirolf

Assignees

@silverweed silverweed

Labels
in:RNTuple
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
3 participants
@silverweed @jblomer @pcanal